This invention relates to bridging of Address Resolution Protocol packets (ARP packets) in computer networks, and in particular to bridging between networks using different canonical format, that is between networks transmitting the least significant bit first to networks transmitting the most significant bit first, and vice versa.
The order of the bits in a data packet is different in different standard computer networks. For example, the bit order for data packets in an Ethernet IEEE 802.3 computer network, or in an older Ethernet network, is in xe2x80x9ccanonicalxe2x80x9d format. In canonical format the least significant bit is transmitted first.
In contrast, IEEE 802.5 token ring networks and Fiber Distributed Data Interface (FDDI) token ring networks have the data packet transmitted in xe2x80x9cnon-canonicalxe2x80x9d format. In non-canonical format the most significant bit is transmitted first.
Networks other than Ethernet may use canonical format in transmission of packets. Also, networks other than IEEE 802.5 and FDDI may use non-canonical format in transmission of packets.
The order of the bits must be swapped for a data packet in canonical format to be understandable by a station using non-canonical format, and vice versa. In particular, for the addresses in the Layer 2 header, the MAC addresses, the order of bits must be swapped for the addressing information of a packet to be understandable by computers on networks using different bit order. That is, the order of the MAC layer (Layer 2) address bits in the packet must be swapped when a data packet is bridged from a source computer network using one canonical format to a destination computer network using the other canonical format, in order for the receiving computer to recognize its own address in the MAC destination address field.
A further difference between Ethernet IEEE 802.3 computer networks and token ring IEEE 802.5 computer networks is that the Ethernet networks use transparent bridging, where in contrast, the token ring IEEE 802.5 computer networks use source route bridging (abbreviated SRB). Again, there may be a variety of computer networks which use transparent bridging, and also a variety of networks which use source route bridging.
Transparent bridging is a method of operating a bridge that forwards a packet from a source LAN to a destination LAN, and where the packet transmitted by the source station is exactly like the packet would be if the destination station were located on the source LAN. In contrast, source route bridging (SRB) is a technique where the packet transmitted by the source station carries a designation of the route which the packet is to follow in order to reach the destination station.
Transparent bridging is ordinarily used to bridge between a number of different types of networks, for example, Ethernet networks, IEEE 802.5 token ring networks, FDDI networks, Asynchronous Transfer Mode (ATM), Serial, and many other networks.
In contrast, SRB is ordinarily used to bridge between only IEEE 802.5 networks, or to bridge between FDDI token ring networks.
Bridges known as Source route, Translating Bridges (SR/TLB bridges) are used to bridge between transparent bridging domains and SRB domains. Often the transparent bridging domains use canonical format in their transmission media, while in contrast, the SRB domain uses non-canonical format in its transmission media. An example is bridging between an Ethernet domain to an IEEE 802.5 token ring domain. MAC addresses are bit swapped when a packet is bridged between canonical to non-canonical media.
The MAC addresses (that is the Layer 2 address) are bit swapped during SR/TLB bridging. In ordinary engineering design, no fields beyond the MAC header are bit-swapped during SR/TLB bridging. A bridge which bridges between media using canonical format to media using non-canonical format is sometimes referred to simply as a translating bridge, or xe2x80x9cTLBxe2x80x9d bridge.
Issues in canonical format and non-canonical format, including translating bridges, are discussed by Radia Perlman in her book Interconnections, published by Addison Wesley with Copyright date of 1992, all disclosures of which are incorporated herein by reference, particularly at pages 31-33. Also, operation of a translating bridge such as a SR/TLB bridge is discussed in documentation provided by Cisco Systems, Inc., on its web page at URL www.cisco.com, and particularly the document xe2x80x9cConfiguring Source Route Bridgingxe2x80x9d, at its xe2x80x9cBridging Between Source-Route Bridge Groups and Transparent Bridge Groups SR/TLBxe2x80x9d section, all disclosures of which are incorporated herein by reference.
As an example, it is standard engineering practice for a SR/TLB bridge, when forwarding a packet from an Ethernet to a token ring, or from a token ring to an Ethernet, that is across a heterogeneous media boundary, to swap the bits of the MAC addresses, but not to swap the bits of the data field. Thus, any data carried in the data field across the boundary between heterogeneous media will not have its bits swapped.
An Address Resolution Protocol packet (ARP packet) is used by a station which desires to send a data packet to a target station, in order to learn the hardware address of the target station, in the event that the sending station knows the protocol address of the target station but does not know the hardware address of the target station. An ARP packet is defined in RFC 826, all disclosures of which are incorporated herein by reference. An RFC is a Request For Comments documents prepared by the Internet Engineering Task Force, or IETF. The RFC documents are available from the IETF web site at the URL www.ietf.org.
In accordance with RFC 826, the sending station generates an ARP request packet having the source station MAC address in the ARP packet Layer 2 source address (SA) field, and a broadcast address in the ARP packet Layer 2 destination address (DA) field.
Also in accordance with RFC 826, the ARP request packet caries information in its data field. In particular, field ar$sha in the data field of the ARP request packet contains the Ethernet hardware address of the sending station, and also field ar$spa of the ARP request packet contains the protocol address (Layer 3 address) of the sending station. An ARP request packet is a search tool used by a sending station to look for an intended target station, arid the protocol address of the desired target station is carried in a field ar$tpa.
In an example wherein all stations are assumed to be operating on a computer network using the same canonical format, all stations receive the ARP request packet because the MAC DA field contains the broadcast address. Upon receipt of the ARP request packet, a receiving station examines the contents of the ar$tpa field. A station recognizing its protocol address (for example, its IP address) then updates its ARP table with the contents of the fields ar$sha and ar$spa read from the data field of the ARP request packet. The target station then transmits an ARP response packet to the sending station. The target station places its hardware address in field ar$sha of the ARP response packet, in order to give its hardware address to the sending station. Also the target station places its protocol address in the field ar$spa of the ARP response packet.
The ARP protocol of RFC 826 works when the packets are bridged from a source computer network to a destination computer network, where both networks use the same canonical format of the bit order. Operation of the ARP protocol is discussed by Radia Perlman in her above mentioned book Interconnections at pages 198-200, and also the ARP protocol is discussed in RFC 826.
However, in the event that the ARP request packet is originated by a sending station on a canonical LAN, and the ARP request packet is bridged from the canonical LAN to a non-canonical LAN by a translating bridge, SR/TLB, or a translating bridge TLB, the MAC address fields will be bit swapped but the data fields will not be bit swapped. So the bridged ARP packet will have the proper source MAC address and the proper broadcast destination MAC broadcast address, but the fields ar$sha, ar$spa, and ar$tpa will not be bit swapped. Accordingly, the intended target station will receive the ARP request packet by recognizing the non-canonical broadcast address in the MAC DA field. However the non-canonical intended target station will update its ARP table with a canonical MAC address of the sending station by reading the ar$sha field of the ARP request packet. When the intended target station sends the ARP reply packet, it fills in the MAC header by using its ARP table, and so writes a canonical destination address into the MAC DA field of the ARP reply packet. The SR/TLB bridge bit swaps the source address in the MAC header into a non-canonical form before transmitting the packet onto the canonical LAN of the source station. So as a result, the source station, which is on the canonical LAN, cannot recognize its own MAC address in the ARP reply packet destination address field. Accordingly, the station which originated the ARP request will not receive the reply.
An example helps to clarify the problem. Suppose that a station E on an Ethernet LAN attempts, at a higher protocol layer, to transmit a packet to a station T on an IEEE 802.5 token ring network. First station E checks its ARP table for an entry for the target destination station T, and finds no entry. Then station E generates an ARP request packet with its Ethernet address in both the MAC SA field and the ar$sha field, and also its IP address in the ar$spa field; and station E also places the IP address of the target destination station in the ar$tpa field. The MAC DA field contains the broadcast address so that each station detecting the packet will receive it and examine the Layer 3 IP field ar$tpa to determine if it is the target end station. The MAC DA and MAC SA fields are now in canonical format, as required by an Ethernet LAN. The translating bridge SRITLB then bit swaps the MAC DA and MAC SA fields, but does not bit swap any of the data fields, the ar$sha field, the ar$spa field, or the ar$tpa field. The MAC DA and MAC SA are now in non-canonical format, as is required for an IEEE 802.5 token ring LAN. All stations detect the ARP Request packet because of the MAC broadcast DA address. The target station T receives the ARP request packet by reading the field ar$tpa and recognizing its IP address. The target station T then updates its ARP table using the contents of the field ar$sha in canonical format.
When the intended target station T sends the unicast ARP reply packet, it fills in the MAC header by using its ARP table, and so writes a canonical destination address into the MAC header of the ARP reply packet. The SR/TLB bridge bit swaps the source address in the MAC header into non-canonical form before transmitting the packet onto the canonical LAN of the source station. So as a result, the source station S, which is on the canonical LAN, cannot recognize its own MAC address in the ARP reply packet destination address field. Accordingly, the station S which originated the ARP request will not receive the reply.
There is needed a method to use ARP request and response packets between hetrogeneous media, that is from a LAN using one canonical format to a LAN using another canonical format, in order to build usable ARP table entries in end stations.
The invention is a new field in an ARP packet which designates the canonical format of the addresses written into fields such as ar$sha (the source station hardware address) and ar$spa (the source station protocol address) so that a receiving station can determine the canonical format used to create these fields. The station receiving the ARP request or ARP response packet can then write its ARP table entry in the correct canonical format for its computer network.
Other and further aspects of the present invention will become apparent during the course of the following description and by reference to the accompanying drawings.